home *** CD-ROM | disk | FTP | other *** search
- Path: gidora.kralizec.net.au!root
- From: jon@zeta.org.au
- Newsgroups: comp.lang.c++
- Subject: Re: locking
- Date: 13 Jan 1996 14:12:09 GMT
- Organization: Kralizec Dialup Internet Sydney, +61-2-837-1183 V.32bis
- Message-ID: <4d8ejp$phs@gidora.kralizec.net.au>
- References: <4d0j6r$1ri@daphne.ecmwf.int> <NITIN.96Jan10103013@more.eng.sun.com>
- Reply-To: jon@zeta.org.au
- NNTP-Posting-Host: dialup08.syd1.zeta.org.au
- X-Newsreader: IBM NewsReader/2 v1.2.5
-
- In <NITIN.96Jan10103013@more.eng.sun.com>, nitin@more.eng.sun.com (Nitin More [CONTRACTOR]) writes:
- >In article <30F3E9C3.15FB7483@intellektik.informatik.th-darmstadt.de> Enno Sandner <enno@intellektik.informatik.th-darmstadt.de> writes:
- >
- >> From: Enno Sandner <enno@intellektik.informatik.th-darmstadt.de>
- >
- >[deleted]
- >
- >> >
- >> > This seems to work, but the LockObject is only destroyed at the
- >> > end of the block, locking my object for too long.
- >> >
- >> > main()
- >> > {
- >> >
- >> > SharedObject<foo> fooH("lock");
- >> >
- >> > ... the lock is not set
- >> >
- >> > fooH->bar();
- >> >
- >> > .. the lock is set until the end.
- >> > }
- >> >
- >> > Anyone got an idea ?
- >> >
- >>
- >> I would say the temporary object should be destroyed directly after
- >> the invocation of 'bar'.
- >> As a workarround you can put the member-function call in brackets, e.g.
- >>
- >> { foo->bar(); }
- >>
- >> Enno
- >
- >You need to put the declaration of fooH also in the block as follows:
- >
- > {
- > SharedObject<foo> fooH("lock");
- > fooH->bar();
- > .. the lock is set until the end **OF THE BLOCK**
- > }
-
- > .. fooH is destructed at the end of the block releasing the lock.
- >
-
- No it isn't.
-
- The temporary created by fooH-> is guaranteed to be deleted
- by the end of the block (ARM 12.2) but it can be deleted before
- that - whether it is or not is implementation dependent.
-
- Refer to my articles in comp.lang.c++.moderated for my other comments
- about implementing locking in this way.
-
- jon.
-